Simultaneous data packet processing

ABSTRACT

A packet controller for simultaneous processing of data packets transmitted via a plurality of communication channels includes a plurality of inputs to receive a respective plurality of signals, such that each of the plurality of signals is indicative of a presence of a data packet on a respective one of the plurality of communication channels, a clock source to supply a periodic clock signal, a plurality of independent processing modules coupled to the respective plurality of inputs to simultaneously process the plurality of signals, such that each of the plurality of independent processing modules implements a respective state machine driven by the periodic clock signal to process the respective signal independently of every other one of the plurality of processing modules, and an output to transmit an output signal indicative of a presence of at least one data packet on one or more of the plurality of communication channels.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a divisional of U.S. patent application Ser. No.12/490,205, entitled “Simultaneous Data Packet Processing,” filed onJun. 23, 2009 (Attorney Docket No. 31244/43714), and based on andclaiming the benefit of priority to U.S. Provisional Application No.61/074,954, entitled “Wireless Communication Network Analyzer” filed onJun. 23, 2008 (Attorney Docket No. 31244/43714P), the entire disclosuresof which are hereby expressly incorporated herein by reference.

FIELD OF TECHNOLOGY

The present patent relates generally to wireless communications and,more particularly, to a device for capturing and analyzing datatransmitted via multiple wireless communication channels.

BACKGROUND

The WirelessHART communication protocol establishes a wirelesscommunication standard for process applications. More particularly,WirelessHART is a secure, wireless mesh networking communicationtechnology operating in the 2.4 GHz ISM radio band. WirelessHARTutilizes IEEE STD 802.15.4-2006 2.4 GHz DSSS transceivers with channelhopping on a transaction by transaction basis. WirelessHARTcommunication is arbitrated using time division multiple access (TDMA)to schedule link activity. All communications are performed within adesignated slot and one or more sources and one or more destinationdevices may be scheduled to communicate in a given slot. Thus, a slotmay be dedicated to communication from a single source device or a slotmay support shared communication access between multiple devices. Themessage being propagated by the source device on a slot may be addressedto a specific device or may be broadcast to each of the destinationdevices assigned to the slot.

To be successful, WirelessHART must support interoperability and allowcompliant devices from different manufactures to be mixed in the samenetwork to create an integrated system. The HART CommunicationFoundation (HCF) has always had a strict definition of interoperability.In particular, HCF defines “interoperability” as the ability for likedevices from different manufacturers to work together in a system and besubstituted one for another without loss of functionality at the hostsystem level.

To attain compliance, the HCF has developed a quality assurance programto ensure the compliance of WirelessHART products. The objective of theWirelessHART quality assurance program is to ensure product adherence tothe high standards of interoperability and compatibility defined by theHCF.

Using the network analyzer or radio capture tools available today, anoperator may monitor an individual communication channel by tuning anetwork analyzer to the radio frequency associated with the channel andattempting to capture data packets transmitted via this communicationchannel. To monitor another communication channel, the operator needs toeither adjust the frequency setting of the network analyzer being used,or use another network analyzer. Thus, to monitor multiple channels atthe same time, the operator needs to set up and operate several networkanalyzers. In addition to the inconvenience, high cost, and stringentcalibration requirements associated with using multiple networkanalyzers at the same time, the operator may also generate undesirableinterference in the respective antennas of the network analyzers whenplacing these devices close to each other.

SUMMARY

A wireless communication network analyzer for use in, for example, anIEEE 802.11 or 802.15-compliant communication network, includes anacquisition engine to capture and process data packets or other dataunits transmitted on multiple wireless communication channels, and auser interface to display information related to the data packets and tosupport channel configuration and selection commands. In someembodiments, the wireless communication network is a WirelessHARTnetwork that operates in a process control environment and communicateson IEEE STD 802.15.4-2006 2.4 GHz channels. The acquisition engineincludes a radio frequency (RF) interface that can capturecommunications on multiple radio channels simultaneously and a packetserver to receive data packets and related statistics (e.g., ReceivedSignal Level (RSL_, Link Quality Indicator (LQI), Cyclic RedundancyCheck (CRC) status) from the RF interface, provide the data packets andthe statistics to the local user interface and/or one or more clientapplications, and control data capture at the RF interface.

The packet server and the user interface may run on a computer host thatsupports a standard operating system such as, for example, Linux, QNX,or Microsoft® Windows 2000, XP, or Vista. The RF interface may beimplemented as a hardware component powered by the computer host via aUSB connection interface such as USB 2.0. The same USB connectioninterface may also support communications between the packet server andthe RF interface. In this manner, the acquisition engine may bemanufactured using commercial, off-the-shelf hardware.

In some embodiments, the communication network in which the networkanalyzer operates is compliant with the 2.4 GHz IEEE Standard802.15.4-2006 (“the Standard”), and the acquisition engine can capturecommunications on all 16 channels specified by the Standard. Theacquisition engine may capture information related to all layers of theprotocol stack, i.e., from the preamble and header associated with thelowest physical (“PHY”) layer up to the complete payload of theapplication layer. In an embodiment, the communication network is asecure mesh WirelessHART network operating in a process controlenvironment. In this embodiment, the network analyzer may performconformance testing of WirelessHART products in addition to sniffingdata packets for the purposes of supervising communications betweendevices.

In some embodiments, the RF interface includes a single antenna receivesa wireless signal that includes all communication channels on which thenetwork analyzer operates, at least one splitter to generate multiplecopies of the received signal, and several radio transceivers to processcommunications on the respective communication channels using the copiesof the received signal. Thus, in one operational mode, each radiotransceiver is tuned to the frequency of the corresponding communicationchannel. In another operational mode, all radio transceivers of the RFinterface are tuned to the same communication channel to performreliable diagnostics of communications on the communication channel. Inthese embodiments, the radio transceivers are tunable. In an embodiment,a user can tune the radio transceivers by entering appropriate commandsvia the user interface of the network analyzer.

To allow the use of a single antenna with a relative large number ofradio transceivers, the RF interface may also include a low noiseamplifier (LNA) disposed upstream of the splitter to compensate for theloss of power that occurs when the splitter slits the received signal.In some embodiments, the LNA provides sufficient power compensation toenable first-stage splitting using a first-stage splitter, andsecond-stage splitting using several second-stage splitters, eachcoupled to a respective output of the first-stage splitter.

In another embodiment, the RF interface includes a bandpass filter thatreceives a signal from a single antenna, a first-stage amplifier coupledto the output of the bandpass filter, a first-stage splitter coupled tothe output of the first-stage amplifier, several second-stage amplifiercoupled to the respective outputs of the first-stage splitter, andseveral second-stage splitters each coupled to the respectivesecond-stage amplifier. In one such embodiment, the first-stage splitterand each of the second-stage splitter is a four-way splitter toaccordingly provide a 16-way split of the received radio signal for useby 16 radio transceivers.

In some embodiments, the RF interface further includes a centralprocessing unit (CPU) such as a microcontroller, and a packet controllerwith at least a transceiver interface, a CPU interface, and a packetprocessing module. The CPU provides data packets captured by the radiotransceivers to the packet server, receives configuration commands fromuser interface to be forwarded to the appropriate radio transceiver,etc. The CPU may receive configuration or control data, and transmitdata packets and related statistics, via the USB interface connectingthe RF interface to the computer host. In some embodiments, the CPU alsoprovides a clock signal for use by other components of the RF interface,including the packet controller. Accordingly, the CPU interface of thepacket controller may include a set of pins to transmit packets from theoutput queue of the packet controller, a pin to output a signalindicative of a presence of one or more data packets in the output queueof the packet controller, and a set of pins to receive a selection of aradio transceiver for control or configuration. In at least some of theembodiments, the CPU interface of the packet controller also includes apin to receive a clock signal, a set of pins defining the known serialparallel interface.

The transceiver interface of the packet controller to the radiotransceivers provides a separate connection to each transceiver. In someembodiments, the transceiver interface includes a group of sets of pins,each set in the group defining the SPI interface to the respectivetransceiver. For each transceiver, the transceiver interface may alsoinclude a pin to receive a signal indicative of the beginning ofreception of a data packet at the transceiver, a pin to receive a signalindicative of the end of reception of a data packet at the transceiver,and a pin to receive a signal indicative of the end of transfer of datapackets from the transceiver to the packet controller. In thoseembodiments where the packet controller has a SPI interface with the CPUand with each transceiver, the packet controller may be considered aserial packet controller (SPC) that operates as a slave device relativeto the CPU and as a master device relative to each transceiver.

The packet controller may further provide independent first-in-first-out(FIFO) buffering for each communication channel, i.e., for data packetsreceived from a particular transceiver. In some embodiments, the packetcontroller implements a separate state machine for each communicationchannel, and drives each state machine in parallel using a common clocksignal. The clock signal may also drive a counter which the packetcontroller may use for time stamping data packets. In this manner, thepacket controller can generate a highly accurate time stamp for eachpacket, so that two packets, A and B, detected simultaneously (i.e.,within the same clock cycle) by two transceivers on the respectivecommunication channels, acquire an identical time stamp. Thus, when thepacket controller forwards the packets A and B to the CPU and,ultimately, to the packet server, the packet A may be forwarded prior tothe packet B or, conversely, the packet B may be forwarded prior to thepacket A. In either case, the packets A and B can be properly processedbecause the packet controller always generates a time stamp thatreflects the time the data packet was received at the respectivetransceiver.

In an embodiment, the packet controller may be implemented as afield-programmable field array (FPGA). The FPGA may be commerciallyavailable off-the-shelf hardware, and the packet controller may beimplemented as firmware. In other embodiments, the packet controller maybe implemented using standard components such as AND and OR gates, forexample, or another type of an application-specific integrated circuit(ASIC). The clock may be a low-drift crystal clock with a resolution andaccuracy selected in view of the duration of a transmission period inthe communication network in which the network analyzer operates. Whenthe communication network is a WirelessHART network, the resolution andaccuracy of the clock is preferably one microsecond to provide reliableanalysis of communications within TDMA timeslots used by WirelessHARTnetworks.

The packet server of the network analyzer may receive a stream of timestamped data packets from the acquisition engine via the USB port. Thepacket server may then provide the stream of data packets to the userinterface as well as to one or multiple clients via a standard networkprotocol such as TCP/IP or UDP/IP, for example. The data stream may beformatted as ASCII text, hex data, or according to any other format. Bysupporting multiple clients, the packet server allows multiple users toremotely connect to the network analyzer disposed in a convenientlocation relative to the corresponding communication network, forexample.

A packet client may be a text-only or a graphical application thatdisplays data packets captured from multiple communication channels in aconvenient and intuitive format. At least some packet clientapplications may include filtering functions. In some embodiments, apacket client is adapted to apply a device-specific filter to displayonly those data packets that travel toward or from the specified networkdevice. Further, a packet client may communicate with multiple packetservers so that a user may, for example, view network communications inseveral places within the communication network. In some embodiments, apacket client supports automated or scripted testing and/or filtering.

In some embodiments, a wireless communication network analyzer adaptedto simultaneously capture and process communications on multiplecommunication channels may include a software component executable on aconventional computer system, and a dedicated external hardwarecomponent that implements the RF interface and communicates with thesoftware component via a standard interface such as USB, for example. Inan embodiment, the software component includes both a packet server anda user interface. In other embodiments, the software component includesa packet server, and the user interface is provided as a separatecomponent executable locally or remotely from the packet server. In yetother embodiments, the packet server alone or in combination with theuser interface may be provided as a dedicated hardware component. In onesuch embodiment, the RF interface along with the packet server and theuser interface are implemented in an embedded system.

In an embodiment, a packet controller for simultaneous processing ofdata packets transmitted via a plurality of communication channelsincludes a plurality of inputs, each to receive a respective data packetsignal indicative of a presence of a data packet on a respective one ofthe plurality of communication channels; a clock source to continuouslysupply a periodic clock signal associated with a certain clock cycle; acounter communicatively coupled to the clock source to generate a clockcycle count defined as a number of instances of the clock cycle thathave occurred since a reference time; and plurality of independent timestamp generators, each coupled to the counter and to a respective one ofthe plurality of inputs to generate a time stamp in response toreceiving the respective data packet signal, such that the time stampincludes a value of the clock cycle count. Optionally, the plurality ofinputs of the packet controller is a first plurality of inputs, and thepacket controller further includes a second plurality of inputs, each toreceive data packers from a respective one of the plurality ofcommunication channels; and an output to output data associated with theplurality of communication channels in a first-in, first-out (FIFO)order.

In another embodiment, a serial data controller for parallel processingof a plurality of communication channels includes a master interface toexchange data with a master device, the master interface having a masteroutput, slave input (MOSI) to receive data from the master device, afirst master input, slave output (MISO) to transmit data to the masterdevice, and a serial clock input (SCLK) to receive a master clock signalfrom the master device; and the serial data controller further includesa plurality of slave interfaces, each to exchange data with a respectiveone of a plurality of slave devices, such that each of the plurality ofslave devices services a respective one of the plurality ofcommunication channels and each of the plurality of slave interfaceshaving a MOSI to transmit data to the respective one of the plurality ofslave devices, a MISO to receive data from the respective one of theplurality of slave devices, and an SCLK output to forward the masterclock signal to the respective one of the plurality of slave devices;each of the plurality of slave interfaces further including amultiplexer having a plurality of inputs coupled to the plurality ofslave interfaces, and an output coupled to the master interface, and aprocessing module to simultaneously process data received from each ofthe plurality of slave interfaces, and coupled to the multiplexer toprovide the data to the master device as a single stream via the masterinterface. Optionally, the serial data controller further includes amode selection input to select between at least a first mode and asecond mode of operation of the serial data controller, such that thefirst mode is associated with transferring data from the plurality ofslave interfaces to the master interface, and the second mode isassociated with transferring data from the master interface to theplurality of slave interfaces. Optionally, the serial data controllerreceives data packets via the plurality of slave serial interfaces, andthe processing module includes a clock source to supply a periodic clocksignal, a counter coupled to the clock source to count a number of clockcycles of the periodic clock signal, and a plurality offirst-in-first-out (FIFO) buffers, each corresponding to a respectiveone of the plurality of slave serial interfaces; so that the processingmodule generates a time stamp for each data packet received via one ofthe plurality of slave serial interfaces, and places each data packetand the corresponding time stamp into one of the plurality of FIFObuffers, where the one of the plurality of FIFO buffers corresponds tothe one of the plurality of slave serial interfaces, and where the timestamp includes the number of clock cycles of the periodic clock signalOptionally, the master interface of the serial data controller furtherincludes a slave device selector to select between the plurality ofslave devices. Optionally, a wireless communication network analyzerincludes the serial packet controller and is adapted to simultaneouslycapture data packets on a plurality of radio channels; the networkanalyzer further including a processor defining the master device, aplurality of radio transceivers defining the plurality of slave devices,each of the plurality of radio transceivers associated with a respectiveone of the plurality of radio channels, and a packet server stored in acomputer-readable memory as a set of instructions and executing on theprocessor to transmit the data packets captured on the plurality ofradio channels to one or more clients.

DETAILED DESCRIPTION OF THE DRAWINGS

FIG. 1 schematically illustrates a wireless network in which a wirelesscommunication network analyzer of the present disclosure may operate,and a fragment of an example schedule according to which devices in thewireless network communicate.

FIG. 2 is a block diagram of the network analyzer of FIG. 1.

FIG. 3 is a circuit board component diagram for an RF interface of thenetwork analyzer illustrated in FIG. 1.

FIG. 4 is a block diagram of a signal peripheral controller of the RFinterface of FIG. 3.

FIG. 5 is a signal diagram for the signal peripheral controller of FIG.3.

FIG. 6A is a block diagram of a state machine interaction of the signalperipheral controller of the RF interface of FIG. 3.

FIG. 6B is a state transition diagram which several independent statemachines operating in the signal peripheral controller of the RFinterface of FIG. 3 may execute to service a particular communicationchannel.

FIG. 7 is a block diagram of a serial peripheral interface interactionof the signal peripheral controller of the RF interface of FIG. 3.

FIG. 8 is a timing diagram of an example scenario in which the networkanalyzer of FIG. 1 captures several data packets on differentcommunication channels.

FIG. 9 is a block diagram of a receive signal transmission path for analternative embodiment of the RF interface of FIG. 3.

FIGS. 10-13 illustrate circuit diagrams for various components of the RFinterface of FIG. 3.

FIG. 14 is a block diagram of a packet client that operates withmultiple packet servers of the network analyzer of FIG. 1.

DETAILED DESCRIPTION

FIG. 1 illustrates an exemplary wireless network 1 in which a wirelesscommunication network analyzer 2 may be used to capture and process datapackets P1-P4 communicated by devices D1-D8. Although the wirelessnetwork 1 may be compatible with a variety of wireless protocols, thenetwork protocol used in the embodiment illustrated FIG. 1 is a secure,wireless mesh protocol that operates in the 2.4 GHz ISM radio band,utilizes IEEE Standard 802.15.4-2006 2.4 GHz DSSS transceivers withchannel hopping on a transaction-by-transaction basis, and scheduleslink activity using time division multiple access (TDMA). Morespecifically, the network protocol operating in the wireless network 1may be the WirelessHART protocol promulgated by the HART CommunicationFoundation (HCF). Accordingly, devices D1-D8 in the embodiment of FIG. 1communicate digital data using data packets of limited length, e.g., notexceeding 128 bytes, during fixed-length timeslots assigned to multiplecommunication channels corresponding to carrier frequencies F₁-F₅. Thedevices D1-D8 support channel hopping to provide frequency diversitythat, in turn, minimizes interference and reduces multi-path fadingeffects.

For ease of explanation, FIG. 1 also schematically illustrates afragment 4 of a network schedule according to which the devices D1-D8transmit and receive the data packets P1-P4. Although the schedule ofthe wireless network 1 generally may specify only timeslot and frequencyassignment for a particular pair of communicating devices, the fragment4 illustrates an example mapping of particular packets P1-P4 to(timeslot, frequency) tuples for a typical communication scenario in thewireless network 1. It will be also noted that although the fragment 4illustrates assignment to only five frequencies F₁-F₅ defining fiverespective communication channels, the wireless network 1 may operateusing fewer or more communication channels. For example, the wirelessnetwork 1 may utilize all 16 communication channels specified by 2.4 GHzIEEE Standard 802.15.4-2006.

With continued reference to FIG. 1, the packet P1 may travel from thedevice D1 to the device D2 during the timeslot TS₁ on carrier orfrequency F₄, and from the device D2 to the device D7 during timeslotTS₂ on carrier F₅. Thus, to trace the propagation of the packet P1 fromthe device D1 to the device D7, it is desirable to capturecommunications on both carriers F₄ and F₅. As another example, thepacket P3 may also travel from the device D1 to the device D7, but viaan additional intermediate device D3. During timeslot TS₂, the packet P3may travel from the device D1 to the device D3 on carriers F₁; thepacket P3 may then travel to the device D2 during timeslot TS₃ oncarrier F₂; and finally to the device D7 during timeslot TS₄ on carrierF₃. It will be noted that during timeslot TS₂, both packets P1 and P3travel between the respective pairs of devices D2, D7 and D1, D3.Therefore, it is also desirable to capture communications simultaneouslyon multiple carriers.

In addition to the packets P1 and P3 that travel “upstream” relative tothe device D7, some of the devices D1-D8 may similarly propagate datapackets P2 and P4 “downstream” from the device D7 to the destinationdevices D5 and D4, respectively. As illustrated in FIG. 1, the packet P2may travel to the device D5 during timeslot TS₁ on carrier F₃, while thepacket P4 may travel may travel between the devices D7 and D5 duringtimeslot TS₃ on carrier F₅, between the devices D7 and D5 duringtimeslot TS₄ on carrier F₁, and between the devices D7 and D5 duringtimeslot TS₅ on carrier F₂.

During operation of the wireless network 1, the network analyzer 2continuously and simultaneously captures communications on all channelsF₁-F₅ used by the devices D1-D8. Further, the network analyzer 2captures and maintains timing information to ensure correct TDMAoperation. To this end, the network analyzer 2 may use a common clocksource to time stamp communications occurring on any channel. Stillfurther, the network analyzer 2 may record all communications to allowthe network traffic to be analyzed for the purpose of assessingcompliance with the network protocol used by the wireless network 1.

Users such as engineers, technicians, etc. may operate the networkanalyzer 2 locally or remotely via the network interface of the networkanalyzer 2. If desired, several instances of the network analyzer 2 mayplaced in several locations in the process control plant, and a user ata remote location may run a single client application that communicateswith the two or more network analyzers 2. Conversely, each networkanalyzer 2 may support multiple client applications by assigningseparate TCP or UDP ports to each instance of a packet client, forexample.

FIG. 2 schematically illustrates example architecture of the networkanalyzer 2, as well as the interaction between the network analyzer 2and one or more client applications (or “packet clients”). The networkanalyzer 2 includes an acquisition engine 10 partially residing on ahost computer 12, which may be a laptop, another type of a standardcomputer system, or an embedded computer system specifically designed tosupport one or several components of the network analyzer 2. Theacquisition engine 10 operates as a data acquisition front end for thenetwork analyzer 2 and, as illustrated in FIG. 2, includes an RFinterface 14 and a packet server 16.

The RF interface 14 includes one or more receive antennas 18 (preferablyonly one) and simultaneously acquires data packets on all communicationchannels used by the wireless network 1, e.g., on all 16 channels of a802.15.4-compliant 2.4 GHz network protocol. The RF interface 14 timestamps the data packets upon reception, and provides the data packets tothe packet server 16 for conveyance to a user interface (UI) 20 of thenetwork analyzer 2 and/or one or multiple client applications 24 via anetwork interface 26 and a network 28. Preferably, the time stamps aresynchronized across all communication channels with less than ±8 μS(micro-seconds) error. The time stamps also preferably have a resolutionof at least 8 μS and preferably have a resolution of 1 μS. In anembodiment, the time stamp corresponds to the reception of the delimiterbyte in the IEEE 802.15.4 PHY PDU. Alternatively, the time stamp maycorrespond to another event such as the reception of the last octet ofthe data packet, for example.

The connection between the RF interface 14 and the packet server 16,which is executed in the host computer 12, may be implemented using aUSB connection port 22, which may be a USB 2.0 full speed (12 Mbits/sec)or a high speed (480 Mbits/sec) connection, and may comply with theappropriate USB device type profile. The RF interface 14 is preferablyappropriately packaged for laboratory and non-hazardous plant floor use.The packaging should also be appropriate for accompaniment by a laptophost computer. Further, packaging should ensure that all 16 channels canbe received equally well. Thus, for example, there should not be morevariance than ±3 dBm in received signal sensitivity between any of the16 channels.

The packet server 16 may be a simple console application that connectsto and supports the RF interface 14. The basic control of the packetserver 16 may be implemented via command-line options. Once launched,the packet server 16 connects to the specified RF interface 14 via theUSB port 22 and waits for the user interface 20 to connect to the packetserver 16 via a predefined control port, for example. The packet server16 may also support one or several data ports to which the userinterface 20 and/or the client applications 24 may connect to retrievedata captured at the RF interface 14. Alternatively, the interactionbetween the packet server 16 and the UI may be implemented remoteprocedure calls (RPCs) or other inter-task communication techniquessupported by the operating system executing on the host 12. Preferably,both the packet server 16 and the user interface 20 are compatible withMicrosoft® Windows 2000, XP, or Vista, as well as with Linux, QNX, andother operating systems.

As discussed in greater detail below, the packet server 16 may support aset of commands which the user may enter directly via the command-lineinterface or via the user interface 20. Once the user interface 20successfully connects to the packet server 16, the user may transmit the“START” to the packet server 16 to initiate transfer of data from the RFinterface 14 to the user interface 20. The data transfer may continueuntil the packet server 16 receives the “STOP” command, or until the UIapplication 20 disconnects.

Still referring to FIG. 2, at least one of the packet clients 24 may bea packet analyzer that displays, filters, and analyzes the data packetsand the statistics captured and collected at the RF interface 14 andforwarded by the packet server 16. Preferably, the packet analyzerunderstands both IEEE 802.15.4 and WirelessHART packet structures.During operation, the packet analyzer may convert the binary fields inthe data packets into legible human-readable display. Further, thepacket analyzer may parse the captured data packets into the separatefields, and optionally display the text included in or corresponding tothe fields to simplify the human analysis and understanding of thecommunications between the devices D1-D8.

In an embodiment, the packet analyzer 24 may run on the same computehost 12, and connect to the packet server 16 locally. Alternatively, thepacket analyzer 24 may run on another host and connect to the packetserver 16 remotely, as illustrated in FIG. 2. Thus, the RF interface 14and the packet server 16 may be located at a plant site, and the packetanalyzer 24 can conveniently connect to the packet server 16 from aservice center to remotely troubleshoot the operation of the wirelessnetwork 1.

As indicated above, the packet analyzer 24 can also connect to multiplepacket servers 16 simultaneously (see FIG. 1 in which two instances ofthe network analyzer 2 are disposed at two different locations withinthe process plant in which the wireless network 1 operates). Moreover,each packet server 16 may support multiple RF interfaces 14. As aresult, data from several geographically distributed RF interfaces 14can be combined on one display to provide a comprehensive view of theentire RF space occupied by the wireless network 1.

Next, FIGS. 3-8 illustrate various components of the RF interface 14 inseveral embodiments, as well as the interactions between thesecomponents from various perspectives to better explain the operation ofthe RF interface 14. In particular, FIG. 3 illustrates an examplecircuit board component diagram of the RF interface 14; FIGS. 4 and 5provide a high-level diagram and a signal diagram, respectively, of oneof the components of the RF interface 14; FIGS. 6A-B and 7 illustratethe same component from the perspectives of state machine execution andserial peripheral interface (SPI) operation, respectively; and FIG. 8illustrates an example signal transmission path of one of theembodiments of the RF interface 14.

Referring to FIG. 3, the RF interface 14 may include an SMA antennaconnector 30 coupled to an RF low noise amplifier (LNA) 32, which inturn is connected to a 4-way signal splitter 34. Each of the outputs ofthe signal splitter 34 is provided to one of a set of 4-way signalsplitters 36 a, 36 b, 36 c, or 36 d. Likewise, each output of the signalsplitters 36 a-36 d is provided to a radio transceiver 38, each of whichreceives and decodes a single radio channel associated with therespective frequency F_(n). Thus, multiple radio transceivers 38 may beincorporated into a single circuit on a single circuit board. Further,the radio transceivers 38, which may be implemented using CC2420 chips,provide a decoded output to a serial peripheral controller (SPC) 40which may include an FPGA module, which may be a Xilinx XC3S1000-FT256chip. The SPC 40 stores these data steams in a set of first-in-first-out(FIFO) buffers or memories, which may be implemented within the SPC 40or in a separate memory chip. The RF interface 14 also includes acentral processing unit (CPU) 42 which is connected to the serialperipheral controller 40 to receive processed data streams and operatesto provide these data steams to the packet server 16 (see FIG. 2). Aserial boot flash memory 44 may store a boot program used to boot up theCPU 42 upon power up and may provide additional non-volatile memory forthe SPC 40.

The CPU 42 may be connected to the host computer 12 (see FIG. 2) via aUSB connection 46 and may be connected to drive one or more lightemitting diodes (LEDs) 48, which may serve as a diagnostic, status oroperational interface on the RF interface 14. An additional radiotransceiver 50, which may also be implemented as a CC2420 chip, isconnected to the CPU 42 and to an SMA antenna connector 52 and may beused as a transmit radio. During operation, the receive antenna 18 (seeFIG. 2) may be connected to the connector 30 and a transmit antenna (notshown) may be connected to the connector 52. These antennas may be, forexample, whip antennas. The CPU 42 may drive the radio transceiver 50 totransmit to the WirelessHART network. However, if desired, the radiotransceiver 50 may be connected to the serial peripheral controller 40via an SPI connection to allow the radio transceiver 50 to be used as anadditional receiver.

As illustrated in FIG. 3, a DC to DC power supply 54 is coupled to theUSB connection 46 to receive power on the USB connection 46, andoperates to convert the USB power to the power levels needed by the CPU42, the serial peripheral controller 40, the radio transceivers 38, 50,the LNA 32 and other powered components on the RF interface 14. Asillustrated in FIG. 2, the power supply 54 may provide 3.3 volt, 2.5volt and 1.2 volt power signals, although other power levels may beprovided as well or instead. Still further, the RF interface 14 mayinclude a JTAG connector 58 to allow programming, diagnostics or otheraccess to the serial peripheral controller 40.

In general, the SPC 40 may perform several functions in the radiointerface 14. On the one hand, the purpose of the SPC 40 is to provideseparate SPI interfaces to each of the 16 802.15.4 radio transceivers38, as well as to the transceiver 50. The SPC 40 may operate as an SPImaster device relative to the transceivers 38 and 50, and as a slavedevice relative to the CPU 42. On the other hand, the FPGA of the SPC 40also provides first-in-first-out (FIFO) buffering, channel selection,start of packet time stamping and a parallel interface to the CPU 42 forcapturing packet data. In addition, the FPGA of the SPC 40 includes aninterface from the CPU 40 for reading and writing all radio and internalFPGA registers as needed.

Referring to FIG. 4, the SPC 40 in one embodiment may include amultiplexer 60 to which several radio control modules 64 providerespective inputs. Each of the radio control modules 64 may control andmaintain a separate FIFO queue to store data packets received at acorresponding transceiver 38. As explained in more detail with respectto FIG. 7, the radio control modules 64 implement independent statemachines driven by a common clock signal, provided by the CPU or anotherclock source. As a result, radio control modules 64 are able to generateaccurate time stamps in parallel and independently of each other. Whenthe radio control modules 64 provide data packets to the CPU 42 via themultiplexer and a read control module 66, these independently generatedtime stamps permit accurate subsequent processing irrespective of theorder in which data packets, received simultaneously or almostsimultaneously on different channels, are supplied to the CPU 42 fromthe multiplexer 60. Upon receiving one or several data packets, the readcontrol module 66 may notify the CPU 42 via an interrupt, for example,prior to outputting the one or several data packets to the CPU 42.Additionally, each of the radio control modules 64 may interact with anSPI interface and global control module 68 to receive control orconfiguration data to be forwarded to a respective radio transceiver 38.

FIG. 5 illustrates a signal diagram of the SPC 40. In this embodiment,the SPC 40 includes a transceiver interface and a CPU interface, each ofwhich may be implemented as a set of input and output pins torespectively receive and transmit electronic signals. Some signals inthe diagram of FIG. 5 are named using the physical channel number as apostfix, e.g., SFD_n, where n is the physical channel number from 0 to15. For the purposes of clarity, these signals are named using thephysical channel number rather than the actual 802.15.4 frequencychannel numbers of 11 to 26. In the discussion of FIG. 5 below, theterms “pin” and “signal” are used interchangeably.

On the transceiver interface, signals MOSI_n, MISO_n, and SCLK_n maydefine a synchronous serial data link consistent with the SPIarchitecture for each transceiver 38. Signals SFD_n, FIFO_n and FIFOP_nmay be used to drive independent state machines responsible for timestamping data packets, as well for initiating and stopping packet datatransfer from the transceivers 38 (state machine implementation isdiscussed in detail with reference to FIGS. 6 and 11). Further, signalsXCVR_CLK_n may be used to forward a clock signal to each transceiver 38.Still further, the transceiver interface may include CS_n signals toselect a particular transceiver 38 chip, and a single outbound resetsignal/NRESET which may be sent to all of the transceivers 38.

Regarding the CPU interface of the SPC 40, eight RXDATA pins are used totransfer a byte to the CPU 42 from a FIFO memory or buffer associatedwith a certain communication channel within the SPC 40, the READ_DATAsignal is used to advance the readout to the next byte, and the /RX_INTsignal is used to generate an interrupt that notifies the CPU 42 thatdata is available in one of the FIFO buffers in the SPC 40. The fivepins ADDR[5:0] are used to select one of the transceivers 38 or one ofthe internal registers of the SPC 40, as discussed in more detail below.Further with respect to the CPU interface, signals MOSI, MISO, and SCLKdefine an SPI interface in which the CPU 42 operates as a master deviceand the SPC 40 operates as a slave device. Still further, the /CS_SPCsignal provides the CPU 42 with access to any register within the SPC40; the /LED1 and /LED2 signals are used to control respectivelight-emitting diodes to indicate network activity or errors, and may beconnected to the CPU 42 so that the CPU 42 can read the LED statesdirectly; the /CLK_(—)16 MHZ signal is used to supply a clock signalfrom the CPU 42 and the SPC_CLK is used for monitoring the internalclock of the SPC 40; and the /RESET_SPC signal from the CPU 42 may resetall or some of the data and/or internal states of the SPC 40.

In general, the SPC 40 may operate in one of two fundamental modes, asetup mode and a receive mode, selectable via the RX_MODE pin. The setupmode is used to initialize the radio transceivers 38, 50 and to transmitpacket data for testing, while the receive mode is used to capture datapackets on all 16 channels simultaneously with a separate SPI bus foreach radio transceiver 38. To enter the setup mode, the RX_MODE pin maybe set to 0, for example.

More particularly, the network analyzer 2 may initially program eachradio transceiver 38 using the setup mode. First, one of the 16 channelsis selected using a set of ADDR[3:0] pins and setting an ADDR4 pin low.These five pins are some of the inputs to the SPC 40 when the SPC 40 isin the setup mode. Next, a normal SPI cycle is performed using the SPIengine run on the CPU 42. A set of /CS_SPC, MOSI, MISO and SCLK signalsare automatically routed through the SPC 40 to the radio transceiver 38associated with the addressed channel. Thus, in the setup mode, the SPC40 can forward signals associated with standard SPI communicationsbetween the CPU 42 and the selected one of the transceivers 38. Formaximum flexibility, the /CS_SPC signal timing is generated by softwarevia a GPIO port in output mode.

In the setup mode, all of the registers of the selected radiotransceiver 38 are programmed, and each transceiver 38 is set to adifferent one of the 16 frequency channels defined by the 802.15.4specification. As the last step performed in the setup mode, the networkanalyzer 2 may write the 16-bit channel enable register within the SPC40 to indicate which ones of the 16 channels are actually enabled in thereceive mode. Once this step is completed, the RX_MODE pin is set to 1to enter the receive mode.

In addition to selecting one of the radio transceivers 38 via theADDR[3:0] pins and transmitting control or configuration data to theselected transceiver 38, the CPU 42 may directly access the internalregisters of the SPC 40 via the /CS_SPC signal by setting ADDR4 signalhigh, for example. In this scenario, the ADDR[3:0] pins may be used toselect one of the 16 internal registers of the SPC 40. In someembodiments, the internal registers are all 16-bits wide. The exactfunctions of the registers of the SPC 40 in one embodiment are definedin the table below.

Register # Name Function Format 0 Channel Enable Selects which channelsBit 15 (MSB) = 1, channel 16 is (Read/Write) are in receive mode enabledafter RX_MODE is set . . . to 1 Bit 0 (LSB) = 1, channel 0 is enabled 1Status (Read Reports internal FIFO Bit 0 = Radio RX FIFO Overflow Only)overflows and/or Radio Bit 1 = SPC RX FIFO Overflow FIFO overflows 4Packet Counte Set to select Counter to Bit 0 to 3 - counter # to be readChannel Address be read back in register 5 Bit 4 - Read Packet Counteror (Write Only) Discarded Packet Counter 5 Read Counter Read back Packet16-bit Packet Counter (Read Only) Counter addressed by register 4 6Debug register 6 Read back Debug Info Variable (read only) 7 Debugregister 7 Read back Debug Info Variable (read only) 15 FPGA FirmwareRead back SPC Read 0x0100 means Version 1.00 Version Firmware VersionIn an embodiment, the register data is clocked in on the positive-edgeof the SCLK signal and is saved in the appropriate register when /CS_SPCgoes high.

In the receive mode, an independent state machine within the SPC 40processes data packets from a respective transceiver 38, and generatestime stamps for each received data packet. The transceiver 38 mayforward all layers of the captured data packet to the SPC 40, includingthe PHY header and possibly the preamble. When the RX_MODE pin is set to1, the SPC 40 automatically sends a command (SRX-ON) to each enabledradio transceiver 38 (identifiable using the channel enable register 0as described in the table above) to start reception. The operation ofthe SPC 40 in the receive mode, as well as the components used in thereceive mode, are discussed next with reference to FIGS. 6A and 6B andcontinued reference to the signal diagram of FIG. 5.

Normally, each radio transceiver 38 is set to a different one of the setof communication channels used to transmit data packets in the network1. As indicated above, the network analyzer 2 may thus capturecommunications occurring on all communication channels of the network 1.However, the network analyzer 2 preferably permits the user to programany of the radio transceivers 38 via the user interface 20 to operate onany 802.15.4 channel. As one example, the user may configure all radiotransceivers 38 of the RF interface 14 to receive communications on thesame channel in order to determine the RSSI signal strength variancebetween communication channels. This mode of operation is referred tobelow as the calibration mode.

As indicated above, the CPU 42 and the SPC 40 use the signalsRXDATA[7:0], READ_DATA and /RX-INT to transfer data packets to the CPU42 and, in particular, the RXDATA pins are used to read a byte from acorresponding FIFO buffer. When transitioning from the receive mode backto the setup mode (i.e., RX-MODE pin goes low), the SPC 40 mayautomatically clear all of the internal states related to the receivemode, and flushes all FIFO buffers.

FIG. 6A schematically illustrates signaling related to independent statemachines 70 that operate in the receive mode of the SPC 40. Each of thestate machines 70 is connected to and services a respective radiotransceiver 38. Referring back to FIG. 4, the independent state machines70 may be a component of a respective independent radio control module54. In particular, each independent state machine 70 may be responsiblefor generating a time stamp in response to detecting the beginning of adata packet, initiating the transfer of a data packet from thecorresponding radio transceiver 38 in response to detecting the end ofthe data packet, and stopping data transfer in response to detectingthat the entire data packet has been transferred to the channel-specificinternal buffer of the SPC 40 from the radio transceiver 38. A statetransition diagram of the state machine 70 in accordance with oneembodiment is illustrated in, and discussed in more detail withreference to FIG. 6B.

Still referring to FIG. 6A, a clock source 72 provides a periodic clocksignal to a counter 74, which may be a 40-bit integer counter, forexample. The clock source 72 may be an accurate, low drift crystal witha resolution and accuracy of 1 microsecond over an interval of greaterthan 12.7 days. If desired, the clock source 72 may be providedseparately from the SPC 40 to provide a clock signal to the SPC 40 via adedicated pin, for example. Each state machine 70 is communicativelycoupled to the counter 74 so that a time stamp for a data packetreceived from any of the transceivers 38 may be generated immediatelyupon detecting the beginning of the data packet at the correspondingtransceiver 38, and irrespective of the number of packets detected onother communication channels. Each state machine 70 may operate arespective packet formatter 76 (which may be another component of theradio control module 54 illustrated in FIG. 4). The packet formatter 76may append, prepend, or otherwise attach the current value of thecounter 74 (defining the time stamp) to the data packet prior to addingthe data packet to the corresponding FIFO queue or buffer.Alternatively, the SPC 40 may include only one packet formatter, and thestate machine 70 may cause the current value of the counter 74 to bestored in a register or buffer for subsequent use by the packetformatter. It will be noted that in general, only some of the processingof data packets needs to proceed in parallel on all communicationchannels. As yet another alternative, the SPC 40 may include multiplecounters 74 driven by a common clock signal.

Each of the state machines 70 may operate according to a statetransition diagram 90 illustrated in FIG. 6B. In this embodiment, thestate transition diagram 90 includes an idle state during which the SPC40 is neither transferring data packets from the correspondingtransceiver 38, nor is registering the reception of a new data packet atthe transceiver 38. The state machine 70 may transition to state 94, inwhich a new data packet is being received at the transceiver 38, whenthe corresponding SFD_n signal goes from 0 to 1. For example, thetransceiver 38 tuned to the frequency F₃ (see FIG. 1) associated withcommunication channel 3 may detect a preamble of a packet on thephysical layer of the 802.15.4 protocol stack, followed by a start framedelimiter (SFD) field indicating the start of the data packet. Upondetecting the frame delimiter, the transceiver 38 may immediately outputa 1 on the outbound SFD pin of the transceiver 38. Because thetransceiver 38 in this example is associated with communication channel3, the SPC 40 receives a 1 on SFD_3 coupled to a state machine 70 thatservices the communication channel 3.

In the notation used in FIG. 6B, the event that triggers the transactionindicated by an arrow is listed to the left of the forward slash, andthe action performed in response to the event prior to entering the newstate is listed to the right of the forward slash. Thus, as illustratedin FIG. 6B, the state machine 70 may generate the time stamp in responseto detecting that the corresponding SFD_n signal is now 1. In a sense,the SFD_n signal is used to “freeze” the packet time stamp for thecorresponding communication channel. Once the last byte of the packet isreceived, the transceiver 38 changes the FIFOP_n signal to high. Thissignal causes the state machine 70 to generate a packet header, initiatean SPI transfer in order to read the data packet bytes from the radioFIFO buffer, and transition to state 96. In an embodiment, eachchannel-specific FIFO buffer may be 2 Kb deep.

Prior to retrieving a data packet in the state 96, the SPC 40 maygenerate a header identifying the channel on which the data packet wasreceived and a 5-byte long time stamp. The SPC 40 may insert thegenerated header into the corresponding FIFO buffer ahead of the datapacket to be retrieved from the transceiver 38 in state 96. In someembodiments, the packet header data format may be defined as follows:

0 1 2 3 4 5 Channel TS Byte 4 TS Byte 3 TS Byte 2 TS Byte 1 TS Byte 0MSB LSB

According to this example format, the lower nibble of the channel byteis in the range 0 to 15 to indicate the physical channel of the packet.The software of the network analyzer 2 may map this physical channel tothe 802.15.4 channel in the setup mode. The upper nibble of the channelbyte carries a copy of the status bits from SPC Register #1 definedabove. The time stamp is preferably a 40-bit value with a resolution of1 microsecond per bit. This resolution allows a packet capture period ofmore than 12.7 days without wrapping. The time stamp counter is set to 0when the SPC 40 is reset at power-up.

In state 96, the state machine 70 may retrieve the data packet availableat the transceiver 38. In other embodiments, the state machine 70 mayread multiple data packets in state 96 without transitioning back tostate 92 after each reception. However, time stamp generation andinsertion may need to be adjusted accordingly. In general, the transferin state 96 may occur via the corresponding SPI interface (i.e., MISO_n,MOSI_n, and SCLK_n pins).

In the example network 1 that implements WirelessHART, the packet datais up to 128 bytes in length. The first byte indicates the length inbytes of the rest of the packet. The SPC state machine first reads thelength byte and uses it to read the remaining bytes of the packet.Alternatively, the SPC 40 can just read the bytes from the radiotransceiver 38 until the FIFO_n pin goes low indicating that there areno more bytes to read.

If desired, the SPC 40 may also append a length check byte at the end ofa data packet stored in the corresponding FIFO. This additional byte isused for synchronization purposes and validation of packet boundaries.Any packets with a length byte greater than 127 may be consideredinvalid and can be discarded. When a discard occurs, a packet discardcounter may be incremented. Packets with valid lengths but with cyclicalredundancy check (CRC) errors also may be captured. The last byte of thepacket may include a bit that indicates whether the packet had a CRCerror.

Once the packet has been received, time stamped and stored in theappropriate channel-specific FIFO memory, the SPC 40 may proceed tonotify the CPU 42 that new data is available for retrieval andsubsequent processing by packet server 16 and, ultimately by one of thepacket clients 24 (see FIG. 1). To this end, the SPC 40 may generate aninterrupt by asserting the /RX-INT pin. The CPU 42 may respond byreading a byte of the packet via the RXDATA[7:0] pins, toggling theREAD_DATA pin to advance the FIFO readout to the next byte, checking tosee whether the /RX_INT pin is still asserted (i.e., checking whetherthe entire data packet has been transferred), and continuing to retrieveindividual bytes of the data packet until the /RX_INT pin isde-asserted.

In some embodiments, to ensure that the CPU 42 can detect thede-asserted /RX-INT pin before the next interrupt comes in, the SPC 40waits to issue any pending interrupts until after the READ_DATA signalis toggled one additional time by the CPU 42.

Further, the SPC 40 may be adapted to efficiently and safely handleoverflows. Although the SPC 40 is preferably fast enough to avoid anoverflow under normal conditions, an overflow may still occur if, forexample, one of the transceivers 38 receives a data packet longer thanthe maximum length of 128 bytes. In this case, an overflow may beindicated by the FIFO_n signal going low after FIFOP_n goes high at theend of the data packet. In an embodiment, the SPC 40 detects thiscondition and issues a command to the corresponding transceiver 38 toflush the associated FIFO memory and to resume operation. In this case,some data in the FIFO buffer is lost and the corresponding time stamp isnot used. This condition could be reported using, for example, one ofthe LEDs 48 on a pin from the SPC 40, if desired.

Further with respect to clock signals used to drive the state machines70, the clock source 72 (see FIG. 6A0) may be the CLK-16 MHz input pin.This signal may be highly accurate clock (+−1.5 ppm), and may be alsoused to drive the time stamp counter 74 and the XCVR_CLK_(—)[16:0]signals. In this case, the SPC 40 may be simply used as a distributionbuffer for the XCVR_CLK_n outputs. The extra XCVR_CLK_(—)16 signal maygo to the radio transceiver 50, if desired.

Further, the SPC_CLK output pin may be the internal clock used by thestate machines 70. This signal is preferably a 40 MHz clock generated byan internal phase locked loop (PLL) of the SPC 40, and this clock signalmay be output at pin for SPC_CLK testing purposes.

As indicated above, the CPU 42 may also completely reset the SCP 40 byissuing a low pulse on the /RESET_SPC input. In this case, the SPC 40may set the one or more counters 70, the internal registers, and all ofthe internal FIFO buffers to zero. The SPC 40 may also reset all of thestate machines to the idle state. The SPC 40 may also send a single/NRESET signal to all of the transceivers 38. Preferably, this signal ispulsed low when the SPC 40 is reset via the /RESET_SPC signal.

When operating in the calibration mode, the network analyzer 2 may tuneall transceivers 38 to the same carrier frequency. The RF interface 14may then receive the same control signal on every communication channel,measure the RSL on each communication channel, and use the obtained RSLmeasurements to compensate for variations in channel-specific signalattenuation in subsequent processing. In other words, the networkanalyzer 2 may operate the transceivers 38 on the same frequency inorder to reduce or completely cancel out channel-to-channel variationsin receiver sensitivity, and thus efficiently and accurately calibratethe RF interface 14. The control signal may include actual data packetstransmitted by the devices D1-D7 in the network 1, or a signal from acontrol transmitter. In one embodiment, the network analyzer 2 may usethe transceiver 50 to generate the control signal having a controlledstrength and/or other parameters. It will be appreciated that accuratecalibration of the RF interface 14 across multiple communicationchannels allows the network analyzer 2 to estimate the strength of thesignal emitted by a device under test (e.g., one of the devices D1-D7illustrated in FIG. 1).

Next, FIG. 7 illustrates the interaction between the CPU 42, the SPC 40,and the transceivers 38 and 50 from the perspective of serial interfacesignaling. In particular, FIG. 7 illustrates only those pins or signalsthat are related to serial interface signaling, and omits other pins orsignals for clarity of illustration. It will be appreciated that the CPU42 in FIG. 7 operates as a master device relative to the SPC 40 which,in turn, operates as a master device relative to transceivers 38 and 50.Although the CPU 42 operates with a single slave device (SPC 40), theCPU interface of the SPC 40 includes ADDR pins (see FIG. 5) that operateas slave selection signals. As discussed above, the configurationillustrated in FIG. 7 advantageously permits the SPC 40 to providebuffering, parallel processing, time stamping, independent management ofFIFO queues dedicated to individual channels, etc.

From the foregoing, it will be appreciated that the radio interface 14in general, and the SPC 40 in particular, permit the client applications24 (see FIG. 1) to receive accurate information regarding the timing ofdata packets transmitted in the network 1. Whereas a conventionalprocessor can only service multiple data streams in a pseudo-parallelmanner, i.e., by slicing the CPU time, the SPC 40 registers criticalinformation such as time stamps on multiple communication channels in agenuinely parallel manner. As is known, parallel processing on aconventional processor typically involves slicing the available CPU timeinto multiple periods for use by parallel task, and switching betweenthe tasks (i.e., “context switching”) according to some algorithm orselection principle. In this sense, parallel processing is onlyquasi-parallel, in that the CPU only performs one task at a given pointin time.

To better illustrate some of the advantages associated with thisapproach, FIG. 8 illustrates a timing diagram in which a data packet isreceived at the time T1 on communication channel 0, as indicated by theSFD_(—)0 signal going high at the time T1, and another two data packetsare simultaneously received at the time T2 on communication channels 1and 2, respectively. If a packet processor such as the SPC 40 is used,the arrival of data packets on communication channels 0, 1, and 2 may bedetected at the time T3, if transitions occur on the falling edge of theclock signal. Thus, all three data packets may acquire the same timestamp even though these three data packets arrive within a single cycleof the CLK signal.

In general, the time stamp accuracy may be limited to the resolution ofthe CLK signal. The data packet detected on communication channel N atthe time T4 may accordingly acquire a time stamp associated with thetime T5 different from the time T3, while the data packets detected oncommunication channels 1 and 2 acquire the same time stamp at the timeT3 despite the difference between the times T1 and T2.

Further, it will be noted that the SPC 40 need not trigger time stampingat the beginning of the delimiter field. If, for example, all packetsare known to use the same format of the PHY preamble and/or header, theSPC 40 may trigger using other signals, or different transitions of thesame signals, received from the transceivers 38. For example, therelative accuracy of time stamps can be the same if the SPC 40 were totrigger on the transition of SFD_n from high to low at the times T6, T7,or T9.

Next, FIG. 9 illustrates another embodiment of the RF signaling pathwhich may be used in the network analyzer 2. Although different from theembodiment of FIG. 3, the configuration illustrated in FIG. 9 alsoallows the network analyzer 2 to use of a single antenna. While FIG. 3illustrates a configuration in which a single band pass filter and highgain amplifier 32 is used to process the RF signals received across the802.15.4 spectrum, FIG. 9 illustrates an alternative RF signal path 98in which a single bandpass filter 100 is disposed between the RF inputand a first stage amplifier 102 which drives the first 4-way splitter34. Second stage amplifiers 104 are then provided between the splitter34 and the 4-way splitters 36 a-36 d. However, it appears to be easierto drive the single amplifier 32 of FIG. 3 using the USB power than thefive separate amplifiers illustrated in FIG. 9. Furthermore, it isdesirable to use a balun for coupling the radios 38 to the antennacoupler itself with a low part count. One possible balun requires onlytwo components instead of seven.

In an embodiment, the SPC 40 may include a Xilinx XC3S1000-FT256 FPGA inwhich the serial slave mode configuration is implemented. In this mode,the CPU 42 controls loading the FPGA code via the CCLK, DIN, DONE,INIT_B & PROG_B pins on the FPGA. The code itself is stored in theserial flash 44 connected to the CPU 42. The CPU 42 is required todownload the FPCA code at power-up time. More details may be found inthe Xilinx Application Note (XAPP502) on using a microprocessor toconfigure a Xilinx FPGA. Further, the radio transceivers 38 may beTI/Chipcon CC2420 chips and the FPCA may be customized to use the signalinterface of this transceiver. FIGS. 10-13 illustrate circuit diagramsfor various components of the RF interface 14, at least some of whichinclude the CC2420 chips.

From the foregoing, it will be appreciated that the radio interface 14discussed with reference to FIGS. 3-9 provides a number of importantadvantages including, for example, simultaneous capture ofcommunications on multiple communication channels, parallel processingof captured streams (and, in particular, accurate-time stamping),ability to capture all layers of a data packet including the physicallayer, etc. Because multiple data streams are processed using the sameclock signal, time synchronization across all 16 channels is assured andaccurate time stamps are generated upon PHY delimiter reception.Moreover, the RF interface 14 may operate using a single antenna tosimultaneously capture data packets on 16 communication channels ormore, if desired. In general, it is also possible to use multipleantennas and, at least in theory, a separate antenna such as a chipantenna may be provided for each communication channel. However, testinghas revealed that placing relatively many antennas proximately to eachproduces significant interference, sometimes enough to cause the networkanalyzer 2 to occasionally drop packets.

Referring back to FIG. 2, the architecture of the network analyzer 2efficiently separates tasks into those that are optimally performed byhardware or firmware, and those that are best performed by software.Thus, the packet analyzer or a similar packet client 24 performs the“heavy lifting” of decoding data packets, processing user commands,displaying data packets textually and/or graphically, etc. Further, thepacket server 16 of FIG. 1 is designed so that data packets are conveyedfrom the RF interface 14 to the user interface application 20 and areformatted accordingly. The command line arguments for the packet server16 may be as follows:

-p port

Server port used to establish a bi-directional configuration and controlconnection to a packet client 24 and/or the user interface 20 (default:1024)

-l descriptor

ISO 639 specified language descriptor string (default: “en”).

-d

Run in debug mode taking input from stdin and sending the capturepackets to stdout. The capture is stopped by sending a AC via stdin. Ifthis option is not specified, the message server will wait for controlcommands on the control port before starting the capture

-O stdout

-   -   file name with optional path (default: “analysaeout.txt”)

-G stdlog

file name with optional path (default: “analysaelog.txt”)

-E stderr

file name with optional path (default: “analysaeerr.txt”)

The user interface 20 and the packet server 16 may use a TCP data portand a TCP control port to communicate with each other. In operation, theuser interface 20 may first assess the connection port for theapplication configuration and control. In one embodiment, the controlport at “localhost” is the TCP port “ANALYS_WH_UI_CONNECT” (localhostrefers to the host computer 12 on which the acquisition engine 10 isexecuting, and ANALYS_WH_UI_CONNECT is a compile-time constant for thedefault port number).

After the user interface 20 connects to the packet server 16 of theacquisition engine 10 via the ANALYS_WH_UI_CONNECT port, the otheruni-directional data port number may be provided as a decimal number inASCII text form. A negative number may indicate a stream allocationerror or some other error condition. The user interface 20 may alsodisplay a list of USB devices attached to the packet server 16.

The user interface 20 can send configuration and control commands to thepacket server 16 using the configuration and control ports. If themessage server 16 accepts the command, it preferably responds with anacknowledgement. If the command contains an error or if the packetserver 16 is unable to complete the command for some reason, the packetserver 16 preferably responds with a negative acknowledgement along witha string of text specifying the reason. The table below provides anexample set of control port commands the packet server 16 may recognize:

Command Description LIST_DEVICES Get a list of devices connected to themessage server. Response is the device number (dd) and the serialnumber/id of device (dd) START dd Start the data stream through the dataport for device dd STOP dd Stop the data stream through the data portfor device dd FILTER Filter parameters

During operation of the network analyzer 2, the acquisition engine 10may provide a data stream to the user interface 20 and/or the packetclients 24 that includes data packets captured on several wirelesschannels as well as additional information useful in device and networkdiagnostics. For example, the data stream may include some or all of thefields Description (e.g., “802.15.4-DATA”), Packet Number (e.g., acontinuously increasing 32-bit number to keep track of each capturedpacket), Date and Time, Timestamp, RSL, Packet Status, Channel, ByteStream, USB Device Number. Additionally, the data stream may include afield USB Device Number to specify the USB device on which the packetwas captured.

In some embodiments, the Date and Time field includes the ISO 8601 datestring, a space character, and the ISO 8601 time string. The secondfield is immediately followed by a decimal point and the number ofmilliseconds. This configuration is similar to the output of thestandard ANSI C library function strftime invoked with the format stringof “% Y-% m-% d % H:% M:% S” with the addition of the milliseconds.Meanwhile, the field Elapsed Time may contain the number of millisecondssince the acquisition system was last reset. The elapsed time isreported every 8 μS and may have an accuracy of at least 8 μS. The timeis preferably represented as a floating point number with three digitsto the right of the decimal point. The value should not overflow for atleast 48 hours.

The RSL field may indicate the receive signal level for each packet,included to provide an estimate of a power level (in dB) of the signalfor the received packet. This value may be represented and stored as asigned integer between −128 and +127.

Further, the Packet Status may be an unsigned, 16-bit enumerated statusof the packet. The status may indicate the following values, forexample: bit 0—Packet FCS Error; Bit 1—Bad receive byte count; Bit2—Receiver overflow. Bits 3-15 are reserved.

Still further, the field Channel contains the decimal channel number asper the IEEE 802.15.4-2006 specifications. The field byte Streampreferably contains all of the bytes received in the data packet. Eachbyte may be separated by a space character and includes 2 hexadecimalcharacters.

In general, all fields may be ASCII text separated by a comma, and thepacket is preferably terminated by a line feed. An example of theresulting stream is:

1, 802.15.4-DATA, 10523, Jul. 16, 2007 14:04:31.261, 6581973.929 , −14,0x0000, 23, 5B 41 88 2C 11 00 . . . equivalent).

FIG. 14 provides another example of an advantageous configuration ofcomponents of the network analyzer 2. In this embodiment, a packetclient 24 connects to multiple instances of the packet server 16. Eachpacket server 16 transmits a stream of data packets to the packet client24 so that the packet client 24 can conveniently display informationfrom multiple physical locations. Moreover, some packet servers 16 mayconnect to multiple RF interfaces, as also illustrated in FIG. 14. Thus,a single packet client 24 can collect a relatively large amount ofinformation related to multiple communication channels and physicallocations.

Because the packet client 24 illustrated in FIG. 14 may collect arelatively large amount of data, filtering functions may be furtherprovided to select data packets based on various criteria such astransmission from or reception at a particular device. Referring back toFIG. 1, for example, an operator may wish to see all data packetstraveling through the device D2. He or she may accordingly select theappropriate filter and apply the selected filter to block all packetsunrelated to D2. It is contemplated that this function may beparticularly useful when verifying compliance of a particular device tothe protocol (e.g., WirelessHART) of the network 1.

It is also contemplated that the network analyzer 2 may be used forautomated test execution as well as test annotation. In particular, thepacket server 16 may be provisioned to execute predefined test scenariosin response to corresponding commands from a packet client 24. In otherwords, the network analyzer 2 can process data packets addressed to thenetwork analyzer 2 itself. For example, packets can be used to instructthe network analyzer 2 to start and stop recording data; to specify thename of the file to record the data; to provide cryptographic keys inuse during the test may be used, etc. The network analyzer 2 may createa specific directory (e.g., on a memory disk of the host 12) to whichthe packet server 16 may direct data packets collected in the course ofexecuting the particular test scenario. In this manner, the amount ofinformation which a human operator has to analyze manually may besignificantly reduced.

Although the forgoing text sets forth a detailed description of numerousdifferent embodiments, it should be understood that the scope of thepatent is defined by the words of the claims set forth at the end ofthis patent. The detailed description is to be construed as exemplaryonly and does not describe every possible embodiment because describingevery possible embodiment would be impractical, if not impossible.Numerous alternative embodiments could be implemented, using eithercurrent technology or technology developed after the filing date of thispatent, which would still fall within the scope of the claims.

1. A radio interface circuit for use in a wireless communication network analyzer that simultaneously captures communications on a plurality of radio frequency (RF) carriers, the radio interface circuit comprising: an RF input to receive a signal associated with the plurality of RF carriers from an antenna; a splitting module communicatively coupled to the RF input to split the received signal into a plurality of signals; wherein the splitting module includes a plurality of outputs at which the splitting module outputs the respective plurality of signals; a plurality of radio transceivers, each coupled to a respective one of the plurality of outputs to process the plurality of signals in parallel and generate a respective plurality of data streams; and a processing unit communicatively coupled to the plurality of radio transceivers to process data associated with the plurality of data streams.
 2. The radio interface circuit of claim 1, further comprising an amplifier disposed downstream of the RF input and upstream of the splitting module to amplify the received signal prior to splitting the received signal at the splitter.
 3. The radio interface circuit of claim 1, wherein the splitting module includes: a first-stage splitter having an input coupled to the RF input, and a multiplicity of outputs; and a multiplicity of second-stage splitters, each having an input coupled to a respective one of the multiplicity of outputs of the first-stage splitter, and a plurality of outputs; wherein the pluralities of outputs of the multiplicity of second-stage splitters define the plurality of outputs of the splitting module.
 4. The radio interface circuit of claim 3, wherein the splitting module further includes a multiplicity of second-stage amplifiers, each disposed between a respective one of the multiplicity of outputs and a respective one of the multiplicity of second-stage splitters.
 5. The radio interface circuit of claim 1, further comprising a packet controller coupled to the plurality of radio transceivers and to the processing unit, the packet controller configured to simultaneously process data packets included in the plurality of data streams to generate an output data stream, and to provide the output data stream to the processing unit.
 6. The radio interface circuit of claim 1, further comprising a clock source to generate a clock signal and provide the clock signal to each of the plurality of radio transceivers.
 7. The radio interface circuit of claim 1, further comprising a packet controller including: a plurality of inputs, each coupled to a respective one of the plurality of radio transceivers; a clock source to supply a periodic clock signal; a plurality of independent state machines, each driven by the periodic clock signal and coupled to a respective one of the plurality of inputs to simultaneously process a respective one of the plurality of data streams; and a multiplexer coupled to the plurality of independent state machines to provide an output data stream that includes data packets from the plurality of data streams; wherein the output data stream is provided to the processing unit.
 8. The radio interface circuit of claim 1, further comprising a packet controller including: a plurality of inputs to receive a respective plurality of data packet start signals from the plurality of radio transceivers, each of the plurality of data packet start signals being indicative of a start of reception of a data packet by a respective one of the plurality of radio transceivers; a plurality of independent processing modules coupled to the respective plurality of inputs to simultaneously process the plurality of data packet start signals, wherein each of the plurality of independent processing modules implements a respective state machine driven by a periodic clock signal to process a respective data packet start signal independently of every other one of the plurality of processing modules; and an output to transmit an output signal indicative of a presence of at least one data packet on one or more of the plurality of RF carriers.
 9. The radio interface circuit of claim 8, wherein the packet controller further comprises a mode selection input to receive a selection signal from the processing unit to select between at least a receive mode and a control mode of operation of the packet controller, wherein: the receive mode corresponds to receiving data packets from the plurality of radio transceivers and forwarding the received data packets to the processing unit, and the control mode corresponds to receiving control data from the processing unit and forwarding the received control data to a specified one of the plurality of radio transceivers.
 10. The radio interface circuit of claim 8, wherein the plurality of inputs is a first plurality of inputs and the output is a first output, and wherein the packet controller further-comprises: a second plurality of inputs to receive a respective plurality of data packet signals from the respective plurality of radio transceivers, each of the plurality of data packet signals conveying the data packet received by the respective one of the plurality of radio transceivers on the respective one of the plurality of RF carriers; a multiplexer coupled to the plurality of independent processing modules; and a second output coupled to the multiplexer to transmit the data packets received on the plurality of RF carriers.
 11. The radio interface circuit of claim 8, wherein: the periodic clock signal is a first periodic clock signal provided by a first clock source having a first clock cycle duration; the packet controller is further configured to receive a second periodic clock signal provided by a second clock source having a second clock cycle duration shorter than the first clock cycle duration; the first periodic clock signal drives state transitions of each of the plurality of independent processing modules, and the second periodic clock signal is used to execute instructions in each of the plurality of independent processing modules.
 12. The radio interface circuit of claim 8, wherein the plurality of inputs is a first plurality of inputs, and the packet controller further comprises a second plurality of inputs to receive a respective plurality of data packet end signals from the plurality of radio transceivers, each of the plurality of data packet end signals being indicative of an end of reception of the data packet by the respective one of the plurality of radio transceivers.
 13. A method for a wireless communication network analyzer to simultaneously capture communications on a plurality of radio frequency (RF) carriers, the method comprising: receiving, at the wireless communication network analyzer, an RF input associated with the plurality of RF carriers; splitting, by the wireless communication network analyzer, the received RF input into a plurality of signals; providing the plurality of signals to a plurality of radio transceivers of the wireless communication network analyzer; generating, in parallel by the plurality of radio transceivers, a respective plurality of data streams from the plurality of signals; and processing, by the wireless communication network analyzer, the respective plurality of data streams to generate process data.
 14. The method of claim 13, wherein receiving the RF input comprises receiving the RF input using a single antenna of the wireless communication network analyzer.
 15. The method of claim 13, wherein at least one of: splitting the received RF input comprises splitting the received RF input into a plurality of copies of the received RF input; splitting the received RF input comprises splitting the received RF input using multiple stages of splitting; or the method further comprises amplifying the received RF input prior to splitting the received RF input.
 16. The method of claim 13, further comprising generating, by each of the plurality of radio transceivers at least one of: (i) a respective packet start signal indicative of a beginning of a data packet included in a respective data stream, or (ii) a packet end signal indicative of an end of the data packet.
 17. The method of claim 13, wherein processing the respective plurality of data streams to generate the process data comprises processing the respective plurality of data streams in parallel.
 18. The method of claim 17, wherein processing the respective plurality of data streams in parallel comprises simultaneously driving a plurality of state machines using a periodic clock signal to retrieve data packets corresponding to a respective plurality of data packet start signals corresponding to respective data packets included in the plurality of data streams.
 19. The method of claim 18, wherein each of the plurality of state machines corresponds to a respective one of the plurality of RF carriers and uses a respective one of the plurality of data streams.
 20. The method of claim 13, wherein processing the respective plurality of data streams to generate the process data comprises multiplexing the plurality of data streams into a single data stream including the process data. 